OpenClaw 教程 OpenClaw Gateway 多节点 Tailscale Tailnet 远程访问

OpenClaw系列第22课：Tailscale 组网 - 跨网络连 OpenClaw

Kai2026-05-102026-05-11

这是「OpenClaw 教程课程」第 22 课。
上一课我们讲了多节点架构：Gateway 是中枢，Node 是外围能力。今天继续往下走：当 Gateway、手机、VPS、树莓派不在同一个网络里时，怎么安全连起来？

图：OpenClaw Gateway 可以放在 VPS、家用服务器或笔记本上，其他设备通过 Tailscale tailnet 或 SSH tunnel 安全连接，不需要直接裸露公网端口。

很多人搭 OpenClaw 多节点，第一反应是：

Gateway 在 VPS 上，我把 18789 端口打开不就行了吗？

不建议。

尤其不建议直接把 Gateway WebSocket 端口裸露到公网。

OpenClaw 的 Gateway 是整个系统的中枢：

聊天入口在这里
Agent 会话在这里
节点配对在这里
工具调用在这里
Control UI / WebSocket 也在这里

所以跨网络连接时，第一原则不是“能不能连上”。

而是：

能不能在不暴露核心入口的前提下安全连上。

这就是 Tailscale 在 OpenClaw 里特别有价值的原因。

一、先说结论：优先用 Tailscale 或 SSH tunnel，不要裸露公网端口

如果你只记一句话，就记这个：

OpenClaw 远程访问的安全默认姿势是：Gateway 保持 loopback，只通过 Tailscale Serve 或 SSH tunnel 暴露给可信设备。

也就是：

1
2
3

Gateway 仍然监听 127.0.0.1:18789
外部设备不直接打公网端口
通过 Tailscale / SSH 建立安全通道

这样做有几个好处：

Gateway 不直接暴露到公网
只有 tailnet 里的设备能访问
可以用 Tailscale identity 或共享密钥做认证
手机、Mac、树莓派、VPS 都能在同一个私有网络里互相访问
以后排错和扩展节点都更清晰

如果你把 Gateway 当成家里的中控大门，那么 Tailscale 就像一条只给自己设备走的私有通道。

图：推荐让 Gateway 继续绑定 loopback，由 Tailscale Serve 或 SSH tunnel 提供远程访问路径，而不是直接开放公网端口。

二、为什么不建议直接开放 Gateway 端口？

OpenClaw Gateway 默认端口通常是：

它承载的是 Gateway 的 HTTP + WebSocket 控制面。

文档里提到：

Gateway WebSocket 默认是 ws://127.0.0.1:18789
远程使用通常走 SSH tunnel 或 tailnet VPN
非 loopback 绑定必须有合适的 Gateway auth
Tailscale Serve / WSS 这类安全端点更适合移动节点

如果你直接：

1	0.0.0.0:18789 暴露公网

风险会明显增大。

因为攻击面包括：

Gateway WebSocket
Control UI
节点 pairing 入口
HTTP API
工具调用相关入口
认证配置错误带来的风险

就算你设置了 token，也不意味着可以随便暴露。

更稳妥的做法是：

1
2
3

公网不可见
只有可信网络 / tailnet / SSH tunnel 可见
再叠加 Gateway auth

一句话：

安全不是只靠 token，而是先减少暴露面。

三、Tailscale 在这里解决什么问题？

Tailscale 可以把你的设备组成一个私有网络，通常叫 tailnet。

加入同一个 tailnet 后，设备之间可以通过：

Tailscale IP
MagicDNS 名称
Tailscale Serve 暴露的 HTTPS 地址

互相访问。

对 OpenClaw 来说，它主要解决三个问题。

1）跨网络访问 Gateway

比如：

Gateway 在 VPS
手机在 5G 网络
树莓派在家里宽带
Mac 在公司网络

它们不在同一个局域网。

但都加入 tailnet 后，就像进入同一个私有网络。

2）不需要公网开放节点

节点通常不需要公网端口。

节点主动连接 Gateway。

你只要让节点能访问 Gateway 的 WebSocket 地址即可。

3）移动设备更容易安全连接

手机节点不适合用明文远程 ws://。

文档里说，iOS / Android 在 tailnet 或 public 路由上，首次连接应使用安全路径：

wss://
Tailscale Serve / Funnel
或其他安全的 Gateway URL

Tailscale Serve 刚好很适合这个场景。

四、OpenClaw 里常见的三种 Tailscale 用法

OpenClaw 文档里讲到几个相关模式：

Tailscale Serve
Tailscale Funnel
直接绑定 Tailnet IP

它们都能和 Tailscale 有关，但适合场景不一样。

五、方式一：Tailscale Serve，推荐给大多数人

Tailscale Serve 的核心思路是：

Gateway 继续监听本机 loopback，Tailscale 在 tailnet 内提供 HTTPS 访问入口。

OpenClaw 文档里的示例配置是：

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

这意味着：

Gateway 仍然只绑定 127.0.0.1
不是直接暴露 18789 到公网
Tailnet 里的设备通过 Tailscale Serve 的 HTTPS 地址访问
Control UI 和 WebSocket 可以通过同一个 Gateway 端口对应的 Serve 路径访问

启动示例：

1	openclaw gateway --tailscale serve

如果配置好后，访问形式通常类似：

1	https://<magicdns>/

实际域名以你的 Tailscale MagicDNS 为准。

Serve 的优势

tailnet 内访问，不公开给整个互联网
HTTPS
Gateway 可以继续 loopback-only
对手机节点更友好
可以配合 Tailscale identity headers

Serve 的注意点

文档里提到：

需要安装并登录 tailscale CLI
tailnet 需要启用 HTTPS
tailscale.mode = "serve" 不等于 Tailscale daemon 已经登录
Serve 只说明 OpenClaw 管理了 Tailscale Serve 暴露方式

还有一点很重要：

Serve 适合 tailnet 内可信设备访问，不代表可以忽略 Gateway auth 和 pairing。

六、Tailscale identity 和 Gateway auth 怎么理解？

OpenClaw Gateway 有自己的 auth 模式。

常见有：

none
token
password
trusted-proxy

当使用 Tailscale Serve，并且：

1	gateway.auth.allowTailscale: true

OpenClaw 可以利用 Tailscale 注入的身份头，例如 tailscale-user-login，来完成部分 Control UI / WebSocket 的认证路径。

但这里不要误解。

它不是“所有接口都免密”。

文档里强调了：

Control UI / WebSocket 可以使用经过验证的 Tailscale identity header
HTTP API，比如 /v1/*、/tools/invoke、/api/channels/*，仍然遵循 Gateway 正常 HTTP auth 模式
node-role 或非 Control UI WebSocket 连接仍然走正常 pairing 和 auth 检查
这个 tokenless flow 假设 Gateway host 是可信的

所以新手理解成这样就够了：

Tailscale 可以帮助识别 tailnet 用户，但它不等于完全取消 OpenClaw 自己的认证和配对。

如果你想更保守，可以设置：

1	gateway.auth.allowTailscale: false

然后继续使用 token 或 password。

七、方式二：Tailnet IP 直接绑定，适合明确知道自己在做什么的人

OpenClaw 也支持直接绑定到 tailnet。

示例配置：

{
  gateway: {
    bind: "tailnet",
    auth: { mode: "token", token: "your-token" },
  },
}

然后从另一台 tailnet 设备访问：

1 2	http://<tailscale-ip>:18789/ ws://<tailscale-ip>:18789

这种方式没有 Tailscale Serve 的 HTTPS 包装。

所以它适合：

你明确要让 Gateway 监听 Tailnet IP
你知道 token/password auth 怎么配
你理解 ws:// 在远程场景里的风险
你能控制 tailnet ACL

注意：

直接 bind 到 tailnet 后，http://127.0.0.1:18789 不一定是你的访问路径。

文档里也提示：loopback 在这种模式下不会按原来的方式工作。

对新手来说，我更建议先用 Serve。

八、方式三：Tailscale Funnel，慎用

Tailscale Funnel 会把服务暴露到公网 HTTPS。

OpenClaw 支持：

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "funnel" },
    auth: { mode: "password", password: "replace-me" },
  },
}

CLI 示例：

1	openclaw gateway --tailscale funnel --auth password

注意这里的重点是：

Funnel 是 public internet，不再只是 tailnet 内访问。

OpenClaw 文档里也说：

Funnel 模式必须使用 password auth，否则拒绝启动
Funnel 需要 Tailscale v1.38.3+
需要 MagicDNS、HTTPS、funnel node attribute
Funnel 只支持部分 TLS 端口，比如 443、8443、10000

我对新手的建议很明确：

没有明确需求，不要用 Funnel。

大多数个人 OpenClaw 部署，用 Serve 就够了。

如果只是自己手机、Mac、树莓派访问 Gateway，Funnel 反而扩大了暴露面。

图：Serve 是 tailnet 内 HTTPS 暴露，Funnel 是公网 HTTPS 暴露，tailnet bind 是 Gateway 直接监听 Tailscale IP。新手优先选择 Serve。

九、SSH tunnel 什么时候更适合？

Tailscale 很好用，但 SSH tunnel 仍然很重要。

文档里说，SSH 是 universal fallback。

适合这些情况：

你已经有 SSH 权限
不想安装或登录 Tailscale
临时排错
公司网络限制 Tailscale
只需要一台客户端连远程 Gateway
macOS app 使用 Remote over SSH 模式

最基本的 SSH tunnel 是：

1	ssh -N -L 18789:127.0.0.1:18789 user@host

意思是：

1 2	本机 127.0.0.1:18789 转发到远程 host 的 127.0.0.1:18789

隧道建立后，你本机访问：

1 2	ws://127.0.0.1:18789 http://127.0.0.1:18789

实际访问的是远程 Gateway。

SSH tunnel 的优势

安全成熟
不需要开放 Gateway 端口
Gateway 可以保持 loopback-only
适合单点远程控制
很适合临时排错

SSH tunnel 的缺点

手机节点不一定方便
多设备长期连接不如 tailnet 顺手
需要维护 SSH key 和隧道进程
隧道断了就访问不了

所以选择建议是：

1
2
3

长期多设备：优先 Tailscale Serve
临时单设备：SSH tunnel 很好用
公网访问：慎用 Funnel

十、手机节点跨网络怎么连？

第 21 课讲过，手机可以作为 Node。

但手机通常不在 Gateway 同一个局域网。

所以手机节点连接 Gateway 时，推荐这样做：

推荐：Tailscale Serve + setup code

如果你的 Gateway 通过 Tailscale Serve 提供 wss:// 或 HTTPS 路径，手机可以通过 QR / setup code 配对。

配对流程大概是：

Gateway 开启 Tailscale Serve
在 Telegram 里向 bot 发送 /pair
bot 返回 setup code / QR 信息
手机 OpenClaw App 打开 Settings → Gateway
扫码或粘贴 setup code
回到 Telegram 查看 pending 并 approve

常见命令：

1
2
3

openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>

文档里特别强调：

setup code 里包含短期 bootstrap token，有效期内要像密码一样对待。

不推荐：公网明文 ws

不要给手机一个公网 ws://公网IP:18789。

移动节点在 tailnet / public 路由上，首次连接应使用安全路径，比如：

wss://
Tailscale Serve
Funnel
其他安全 Gateway URL

如果只是私有 LAN 里测试，情况会简单一些。

但跨网络时，优先别走明文远程 ws://。

十一、树莓派节点跨网络怎么连？

树莓派很适合放在家里局域网。

如果 Gateway 在 VPS，你可以让树莓派作为 node host 连接回 Gateway。

一个思路是：

VPS 跑 Gateway
VPS 开 Tailscale Serve 或 tailnet bind
树莓派加入同一个 tailnet
树莓派启动 openclaw node run
节点主动连接 Gateway WS

示例命令形式：

1	openclaw node run --host <gateway-host> --port 18789 --display-name "Home Pi Node"

如果你用的是 Serve / HTTPS 路径，具体连接方式要按你的 Gateway URL 和 OpenClaw 当前 CLI 支持来配置。

这一课先讲架构和路径，不展开所有平台差异。

要点是：

树莓派不需要暴露公网端口，它主动连回 Gateway。

这比“公网访问树莓派”安全很多。

图：手机和树莓派都作为节点连接 Gateway。Gateway 可以在 VPS 上，节点通过 tailnet 或安全隧道连回，不需要暴露节点公网端口。

十二、Gateway 放 VPS 时的推荐方案

这是最常见的部署。

适合人群

希望 OpenClaw 7x24 在线
需要 Telegram / Webhook 常驻
家里设备可能睡眠或断网
有多个节点要连接

访问方式

Control UI：走 Tailscale Serve HTTPS
手机节点：走安全 setup code / QR
树莓派节点：走 tailnet 到 Gateway
临时 CLI：也可以用 SSH tunnel

不建议

直接开放 18789 公网端口
把 gateway.auth.mode 设置成 none 后暴露公网
对所有 IP 放开防火墙
还没理解 pairing 就 auto approve 大网段

十三、Gateway 放家里服务器时的推荐方案

如果你的 Gateway 跑在家里，比如 NAS、Mac mini、家用 Linux 主机：

十四、Gateway 放笔记本时的推荐方案

笔记本适合开发测试，但不适合长期在线。

如果你只是自己开发：

1 2	笔记本跑 Gateway 手机 / 另一台机器通过同一 tailnet 访问

可以。

但要注意：

笔记本睡眠后 Gateway 不可用
网络切换会影响连接
移动节点可能断开
cron / heartbeat 不稳定

如果你希望 24 小时可用，还是建议 Gateway 放：

VPS
家用服务器
NAS
长期开机的小主机

笔记本更适合作为 Node，而不是长期 Gateway。

十五、MagicDNS 比 IP 更适合长期使用

Tailscale 有 MagicDNS。

相比直接写 Tailscale IP，我更建议写 MagicDNS 名称。

原因是：

名字比 IP 好记
IP 可能变化
设备重装或重连后更容易恢复
文档里也提到 macOS app 现在更偏好 MagicDNS 名称

比如你可以把 Gateway 理解成：

1	openclaw-vps.<你的-tailnet>.ts.net

而不是：

100.x.y.z

实际名称以你的 Tailscale 控制台显示为准。

十六、跨网络连接和 pairing 是两件事

很多人会混淆：

我已经通过 Tailscale 连上了，为什么还要 pairing？

因为它们解决的是两个不同问题。

Tailscale 解决网络路径

它回答：

这台设备能不能到达 Gateway？

Pairing 解决设备信任

它回答：

Gateway 是否信任这个设备作为 operator 或 node？

所以完整路径是：

先有网络可达
再有 Gateway auth
再有 device pairing
再看 node command policy
再看具体工具权限

不能因为用了 Tailscale，就跳过 OpenClaw 的安全模型。

图：Tailscale 解决网络可达，Gateway auth 解决连接认证，pairing 解决设备信任，command policy 和 approvals 决定能力边界。

十七、不要滥用 autoApproveCidrs

第 21 课提到过，OpenClaw 支持对节点 pairing 做可选的 trusted CIDR auto-approve。

配置大概像：

{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}

它的意思是：

某些可信网段内的首次 node pairing 可以自动批准。

但我不建议新手一上来就开。

尤其不要写：

1	autoApproveCidrs: ["0.0.0.0/0"]

这相当危险。

更稳妥的顺序是：

先手动 approve
确认节点身份和能力
确认网络边界
只对非常可信、非常小的网段考虑自动批准

十八、一个推荐的最小实战流程

下面是一个比较稳的入门流程。

第一步：确认 Gateway 本地正常

1 2	openclaw status openclaw gateway status

确认 Gateway、模型、聊天渠道都正常。

第二步：安装并登录 Tailscale

在 Gateway 主机上安装 Tailscale，并登录同一个 tailnet。

检查：

1	tailscale status

如果这一步不通，先不要动 OpenClaw。

第三步：启用 Tailscale Serve

可以用 CLI 启动：

1	openclaw gateway --tailscale serve

也可以在配置里使用：

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

第四步：用另一台 tailnet 设备访问

从手机或另一台电脑访问：

1	https://<magicdns>/

如果打不开，先检查：

Tailscale 是否登录
MagicDNS 是否开启
tailnet HTTPS 是否启用
Gateway 是否在运行
Serve 是否真的生效

第五步：再配对节点

节点连接 Gateway 后，查看待批准设备：

1	openclaw devices list

批准：

1	openclaw devices approve <requestId>

第六步：检查节点状态

1
2
3

openclaw nodes status
openclaw nodes list --connected
openclaw nodes describe --node <idOrNameOrIp>

第七步：只测试低风险能力

先别一上来就开摄像头、屏幕录制、远程命令。

先看状态、capability、permissions。

第八步：再逐步开启具体能力

比如 camera、location、node exec。

每开一种能力，都确认：

节点声明了 command
Gateway policy 允许
设备系统权限允许
App 在前台或满足平台要求
exec approvals 符合预期

十九、常见问题：Serve 开了但还是连不上

可以按这个顺序排查。

1）Tailscale 本身是否在线

1	tailscale status

如果 Gateway 主机不在 tailnet，OpenClaw 配再多也没用。

2）Gateway 是否正常

1 2	openclaw gateway status openclaw status

3）Gateway 是否绑定到了预期模式

如果你希望 Serve，就应该保持：

1	gateway.bind: "loopback"

如果你用了 tailnet bind，就不是同一个访问模型。

4）MagicDNS 是否启用

Tailscale 控制台里需要启用 MagicDNS。

5）HTTPS 是否启用

Serve 需要 tailnet HTTPS 支持。

6）客户端是不是同一个 tailnet

不同账号、不同 tailnet，当然访问不到。

7）是否被 ACL 限制

Tailscale ACL 可能限制设备之间访问。

8）Gateway auth 是否缺失

如果访问控制 UI / WebSocket 时要求 token 或 password，就要按配置提供。

图：排查 Tailscale 远程访问时，建议按网络、DNS、HTTPS、Gateway、认证、设备配对、节点状态的顺序逐层检查。

二十、常见问题：节点能到 Gateway，但 pairing 不出现

可能原因：

节点没有真的连接到 Gateway WS
setup code / bootstrap token 过期
URL 写错
使用了不被接受的明文远程 ws://
手机 App 没有完成连接步骤
Gateway 日志里已经拒绝了连接

可检查：

1
2
3

openclaw devices list
openclaw nodes status
openclaw gateway status

如果还不行，再看日志。

第 23 课会专门讲节点配对排错。

二十一、常见问题：用了 Tailscale 还要 token 吗？

看你的配置。

如果使用 Serve，并且 gateway.auth.allowTailscale: true，某些 Control UI / WS 路径可以走 Tailscale identity。

但我对新手的建议是：

刚开始不要追求“免 token”，先用明确的 token/password，更容易排错。

尤其是：

HTTP API
tools invoke
node-role 连接
非 Control UI WS

不要假设它们都能靠 Tailscale identity 自动通过。

二十二、常见问题：我可以用 Funnel 吗？

可以，但多数人不需要。

Funnel 适合这些情况：

你确实要让非 tailnet 用户访问
你理解公网暴露风险
你配置了强 password auth
你知道 Tailscale Funnel 的限制
你能接受更大的攻击面

不适合：

只是自己手机访问
只是家里树莓派连 VPS
只是远程控制个人 Gateway
还没搞清 Gateway auth 和 pairing

所以默认建议：

1	Serve > SSH tunnel > Tailnet bind > Funnel

这不是绝对顺序，而是给新手的安全优先级。

二十三、常见问题：为什么手机不能直接用 ws://tailnet-ip:18789？

文档里提到，移动节点在 tailnet / public 路由上，首次连接应使用 secure path。

比如：

wss://
Tailscale Serve
Funnel
其他安全 Gateway URL

原始 ws:// 更适合 loopback 或受控私有 LAN 场景。

跨网络、移动设备、首次 pairing，不要图省事。

二十四、适合新手的提问模板

下面这些句子可以直接复制给 OpenClaw。

1）规划远程 Gateway

1	我想把 OpenClaw Gateway 放在 VPS 上，手机和树莓派作为节点连接。请帮我设计 Tailscale Serve 方案，不要建议裸露公网 18789 端口。

2）检查 Tailscale 状态

1	请只读检查当前机器的 Tailscale 和 OpenClaw Gateway 状态，确认是否适合开启 Tailscale Serve。

3）排查 Serve 访问失败

1	Tailscale Serve 开启后我访问 MagicDNS 地址失败。请按 tailscale status、MagicDNS、HTTPS、gateway status、gateway bind、auth 这几个方向排查。

4）判断该用 Serve 还是 Funnel

1	我的需求是自己手机和家里树莓派访问 OpenClaw Gateway。请比较 Tailscale Serve 和 Funnel，优先给安全方案。

5）检查是否有公网暴露风险

1	请帮我检查 OpenClaw Gateway 是否有公网暴露风险，只做只读检查，不要修改防火墙或配置。

6）设计手机节点配对路径

1	我想让手机 OpenClaw App 跨网络连接 VPS Gateway。请设计 Tailscale Serve + setup code 的配对流程，并说明哪些 token/code 要保密。

7）设计树莓派 node host 路径

1	Gateway 在 VPS，树莓派在家里局域网。请帮我设计树莓派通过 Tailscale 作为 node host 连回 Gateway 的方案，不要让树莓派暴露公网端口。

二十五、这一课最值得记住的几句话

第一句：

Tailscale 解决的是网络可达，不替代 OpenClaw 的认证、配对和权限控制。

第二句：

新手优先用 Tailscale Serve，让 Gateway 保持 loopback-only。

第三句：

不要裸露 Gateway 端口，尤其不要把 18789 直接开到公网。

第四句：

节点主动连 Gateway，不要反过来把每个节点都暴露出去。

二十六、总结

今天这节课，我们讲了 OpenClaw 跨网络连接的核心思路：

Gateway 是中枢，跨网络连接要先保护 Gateway。
不要直接裸露 Gateway WebSocket / Control UI 端口。
推荐让 Gateway 保持 loopback，再通过 Tailscale Serve 或 SSH tunnel 访问。
Tailscale Serve 适合大多数个人多节点场景。
Tailnet bind 适合更明确的高级部署。
Funnel 是公网暴露，能不用就先不用。
SSH tunnel 是可靠的 fallback，适合临时或单设备远程控制。
手机节点跨网络配对应优先用 secure path，比如 Tailscale Serve / wss://。
树莓派节点应该主动连回 Gateway，不要暴露自己的公网端口。
Tailscale 只解决网络路径，pairing / auth / policy / approvals 仍然要保留。

如果第 21 课解决的是“多节点怎么分工”，那第 22 课解决的就是：

这些节点不在同一个网络里时，怎么安全连起来。

有了这一课的基础，下一课排查 QR、setup code、节点连接失败就会更容易。

下一课预告

下一课我们会讲：

第 23 课：节点配对排错——QR / 手动连接失败怎么办

会重点讲：

setup code 失效怎么办
QR 扫了没反应怎么办
devices list 看不到 pending 怎么办
paired 了但 nodes status 没有怎么办
auth、pairing、node role、capabilities 怎么分层排查
移动端后台限制和系统权限怎么判断

🦞 本文由八条撰写，持续更新中。